Certain known software, when executed on a server, enables the server to send data including display information over a network to a remote client machine for display to a remote operator. For example, certain software enables a processor to function as a web server by sending hypertext markup language (HTML) files stored on a storage device of the server to a plurality of remote clients for viewing. Such web server software typically requires the remote client to install additional software, known as browser software, to interpret and correctly display the information contained within the HTML files. This browser software does not typically correspond with particular server software—rather, the browser software is configured to interpret any HTML file generated and served by any web server.
Certain server software is configured to send files other than HTML files for display on a remote client. For example, certain software enables servers to send interactive files such as common gateway interface (CGI) files or scripting language (e.g., JAVASCRIPT) files for execution on or by the remote client. By sending CGI or scripting language (e.g., JAVASCRIPT) files, this server software can enable more robust interaction between the operator at the remote client and the server, such as by displaying real-time data from a database without creating an HTML file or enabling the operator at the remote client to remotely modify a database stored on the server.
Even though certain server software enables more robust interaction between the remote operator and the server, the CGI or scripting language (e.g., JAVASCRIPT) files sent by such software pose a number of problems in many client/server environments. In industries such as the insurance industry, such CGI or scripting language (e.g., JAVASCRIPT) files can enable the robust interaction with a remote database which is not facilitated by flat HTML files. However, such files typically require additional software installed on the remote client (or more robust browser software) which includes an interpreter for interpreting the code sent over the network. Thus, the hardware requirements of the remote client are more demanding. Moreover, if a server operator desires to send data representing visually complex data such as interactive, tiered menu data, CGI and scripting language (e.g., JAVASCRIPT) files to adequately display such data are especially complex. Since a CGI or a scripting language (e.g., JAVASCRIPT) file may rely on the browser (and hence the processor of the remote client) to do a relatively large percentage of the processing necessary to adequately display these complex menu systems, remote clients with outdated or insufficient hardware capabilities can have difficulty displaying the desired data. Particularly in an industry wherein an individual insurance agent may not have the technological wherewithal to maintain an appropriately capable hardware setup, enabling interaction with data stored at the server using CGI or scripting language (e.g., JAVASCRIPT) files can prove to be an unworkable solution.
Even though certain server software enables more robust interaction between the remote operator and the server, the CGI or JavaScript files sent by such software pose a number of problems in many client/server environments. In industries such as the insurance industry, such CGI or JavaScript files can enable the robust interaction with a remote database which is not facilitated by flat HTML files. However, such files typically require additional software installed on the remote client (or more robust browser software) which includes an interpreter for interpreting the code sent over the network. Thus, the hardware requirements of the remote client are more demanding. Moreover, if a server operator desires to send data representing visually complex data such as interactive, tiered menu data, CGI and JavaScript files to adequately display such data are especially complex. Since a CGI or a JavaScript file may rely on the browser (and hence the processor of the remote client) to do a relatively large percentage of the processing necessary to adequately display these complex menu systems, remote clients with outdated or insufficient hardware capabilities can have difficulty displaying the desired data. Particularly in an industry wherein an individual insurance agent may not have the technological wherewithal to maintain an appropriately capable hardware setup, enabling interaction with data stored at the server using CGI or JavaScript files can prove to be an unworkable solution.
Another drawback associated with sending executable files such as CGI or scripting language (e.g., JAVASCRIPT) files for remote display is that such files are not secure from interception and malicious use. Rather, such files have very predictable, non-proprietary header structures. Even if the file is sent as a binary file, Interception of such an unknown binary file enables a malicious operator to easily determine that the binary file is an executable file, execute the file, and gain access to the server using the functionality enabled by the intercepted file. Particularly in industries such as the insurance industry, data to which server operators desire to provide access can very sensitive, such as data personal identification information (i.e., Social Security Numbers, drivers license numbers), health information (i.e., results of medical testing for a life insurance company), and other sensitive information. Thus, standard, known executable files interpretable by standard browser software may provide an unworkable solution.
Another drawback associated with sending executable files such as CGI or JavaScript files for remote display is that such files are not secure from interception and malicious use. Rather, such files have very predictable, non-proprietary header structures. Even if the file is sent as a binary file, Interception of such an unknown binary file enables a malicious operator to easily determine that the binary file is an executable file, execute the file, and gain access to the server using the functionality enabled by the intercepted file. Particularly in industries such as the insurance industry, data to which server operators desire to provide access can very sensitive, such as data personal identification information (i.e., Social Security Numbers, drivers license numbers), health information (i.e., results of medical testing for a life insurance company), and other sensitive information. Thus, standard, known executable files interpretable by standard browser software may provide an unworkable solution.
Finally, certain known server software is not configured to elegantly handle events which occur at and are trapped by the remote client. Current computer systems generate thousands of events, most of the events being invisible to the operator, during standard use of the system. For example, current computer systems may generate input events such as mouse down, mouse up, mouse over, mouse out, double click, button press, and button release events. The quantity of events generated by an operator simply browsing displayed data that sending data representative of each event to a server can strain even broadband internet or network connections. Moreover, certain known software is configured to statically handle a set of events regardless of the data being sent from the server to the remote client. Thus, while certain interaction may require robust event handling (i.e., dynamically browsing a menu-intensive web page with links to a plurality of database items, which benefits from handling a plurality of mouse, keyboard, and/or other input device events), other interaction requires substantially less robust event handling (i.e., enabling a user to login, which can be sufficiently implemented by handling only keystroke events). Known software does not enable customization of the handling of events—rather, an all-or-nothing approach is typically taken, wherein either data representative of any event trapped at the remote client is sent to the server, or no data is sent to the server regardless of the type of event which is trapped. Each option is problematic: sending data representative of all trapped events can be extraordinarily burdensome for even a broadband network connection, and sending no data representative of trapped events severely limits the functionality enabled by the server. The lack of customizability of such functionality can be particularly cumbersome and harmful in the insurance industries, wherein as discussed above, functionality is frequently sacrificed due to inadequate hardware at remote clients and inadequate network connectivity.